1. Field of the Invention
The present invention generally relates to object-oriented programming (OOP), and in particular to OOP systems supporting the C++ and Java(trademark) programming languages.
2. Description of the Related Art
Object-oriented programming languages provide a number of features such as classes, inheritance, and virtual methods. These object-oriented features have several advantages. In particular, they enable the creation of class libraries that can be reused by many different applications, in many different contexts.
Class libraries are usually distributed separately from applications that use them. A disadvantage of this traditional distribution model is that the shipped class libraries can be very large, and hence require large amounts of space to store them, and large amounts of time to download them. In cases where an application only uses a small part of a class library""s functionality, distribution of the entire library is often undesirable, because the user effectively pays a penalty for unused library features. A more detailed description of such problems is set forth in Tip et al., xe2x80x9cPractical experience with an application extractor for java(trademark),xe2x80x9d In Proceedings of the Fourteenth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA""99) (Denver, Colo., 1999), herein incorporated by reference in its entirety.
To address this problem, application extraction tools have been designed and implemented. Such tools are discussed in Agesen et al., xe2x80x9cSifting out the gold: Delivering compact applications from an exploratory object-oriented programming environment,xe2x80x9d In Proceedings of the Ninth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA""94) (Portland, Oreg., 1994), ACM SIGPLAN Notices 29(10), pp. 355-370; Agesen, xe2x80x9cConcrete Type Inference: Delivering Object-Oriented Applications,xe2x80x9d Sun Microsystems Laboratories Technical Report SMLI TR-96-52, December 1995; Tip et al., xe2x80x9cPractical experience with an application extractor for java(trademark),xe2x80x9d In Proceedings of the Fourteenth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA""99) (Denver, Colo., 1999); IBM Smalltalk User""s Guide, version 3, release 0 ed., IBM Corp, 1995, Chapters 36-38; Smalltalk/V for win32 Programming, Digitalk Inc., 1993, Chapter 17; and ParcPlace Smalltalk, objectworks release 4.1 ed., 1992, Sections 16, 28; herein incorporated by reference in their entirety. Such tools can perform a static whole-program analysis of the application along with the libraries that it depends on to determine the parts of the library and the application that are used. Subsequently, program transformations and optimizations are performed that eliminate the unused functionality of the application and the library, thereby reducing both application size and download time.
Modern object-oriented programming environments such as the Java(trademark) platform load object oriented programs dynamically, create object instances dynamically when they are needed, and link such object instances dynamically for execution. In addition, such platforms typically include a reflection mechanism by which an object-oriented program can fetch information about a class of objects, or access program components by specifying their name. For example, a program can inquire about the name of a class associated with an object reference, or the number of methods defined in a class. Dynamic loading is another example of reflection. Here, the programmer instructs the platform to load a class with a specified name, after which instances of this class can be created. For a more detailed description of the Java(trademark) reflection mechanism, see McManis, xe2x80x9cTake an in-depth look at the Java(trademark) Reflection APIxe2x80x9d, http://www.javaworld.com/jw-09-1997/jw-09-indepth.html, herein incorporated by reference in its entirety. The use of reflection poses a problem for application extraction tools because a static analysis alone cannot determine which classes are instantiated using reflection, and which methods are invoked using reflection. Without this information, a safe approximation of the application""s call graph cannot be constructed; and without a safe call graph, it is unclear which methods are unused so that extraction of the application is impossible.
In order to handle applications that use reflection, or applications that uses class libraries in which reflection is used, application extraction tools require additional information from the user. In current application extraction tools, this information takes the form of a list of the classes, methods, and fields in an application that are accessed using reflection. This information is then used to construct a safe approximation of the call graph, and the application can be extracted safely. The drawbacks of this approach have to do with the fact that the set of program components accessed using reflection in a class library depend on the library features used by an application. Hence, if a user wants to extract multiple applications with regard to the same library, he is faced with two options:
(1) Construct a global list of program components in the library that may be accessed anywhere in the class library using reflection. This list can safely be used for extracting any applications with respect to the library; or
(2) For a given application that is to be extracted with respect to the library, construct a list of program components in the library that are accessed using reflection in the parts of the library used by that application.
Option (1) has the advantage that only a single xe2x80x9cconfiguration filexe2x80x9d needs to be written for the library, but it has the disadvantage of being overly conservative: the extracted applications may contain parts of the library that they do not use.
Option (2) has the advantage that each application is extracted only with the parts of the library that it uses, but it has the disadvantage that a separate configuration file is required for each application.
Therefore, there is a need in the art to provide a mechanism for accurately and efficiently extracting object-oriented components of a library that are potentially used in the execution of multiple applications.
The problems presented above and the related problems of the prior art are solved by the present invention, method, and apparatus for accurately extracting library-based object-oriented applications. The present invention is capable of accurately extracting multiple applications with respect to a class library. The invention relies on a single configuration file for the library, which describes how program components in the library should be preserved under specified conditions. The invention may be used in application extraction tools, and in tools that aim at enhancing performance using whole-program optimizations.
The invention may be used as an optimization to reduce application size by eliminating unreachable methods. In the alternative, the invention may be used as a basis for optimizations that reduce execution time (e.g., by means of call devirtualization), and as a basis for tools for program understanding and debugging.